分享一下在字节内部的视角，在 Rspack 正式开源前一周，因为要开发一个下载页，我选择了使用 Rspack 搭建了一个 React + Arco Pro 的项目。整个项目不复杂，只有一个表单、选项卡和几个 Button 组件。在第一次启动项目的瞬间，我找到了时隔多年第一次开发 HTML 页面的感觉（反馈快、配置简单），因为 Rspack 在冷启动、热更新、构建上表现真的很惊艳它能带给了我非常快速的反馈，热启动时间不到 1 秒，热更新时间只有 50 毫秒，在公司的 CD 环境中，构建时间只有 5 秒左右。在代码推送到部署上线，整个过程不到一分半钟。相比较其他工程化工具，Rspack 的配置简单，不需要过多配置各种 loader 和 plugin，从普通开发者的视角来看，这无疑大大提高了开发体验。

当然，你可能会认为我的场景过于简单。为了提高项目的可维护性和迭代效率，我使用了 React 的 JSX 语法、Arco 组件库。在今天的前端工程化中，即使开发简单的页面，你也会用到大量的第三方依赖。随着依赖的增加，冷启动和构建速度势必会递减。

前端社区发展到今天拥有大量的丰富的生态，在硬件、Web 标准和生态的发展进一步推动了 Web 应用的发展，Web 项目上出现了一大批原来只能在 PC 软件上出现的产品：Figma、云文档、Photoshop，这些场景进一步导致了前端工程的复杂度和参与的人数规模，开发体验、构建速度已经成为这些产品的迭代效率的瓶颈了。

我曾协助公司内某个业务排查一次技术变更带来的性能影响，通过公司内提供的性能分析平台，在增加一些性能埋点之后，通过性能实验室跑性能分析：项目构建 + 性能分析 50分钟过去了，最终发现我少加了部分埋点导致无法准确的分析具体性能影响的范围，当时我的心情非常沮丧。在字节内部，类似的场景非常多，存在大量的复杂中台场景。很多一线的研发同学深有体会，如何在保留现有整体生态、内部插件的基础上提升构建速度和冷启动速度，是一个非常具有挑战性的问题，在没有足够的动力的情况下贸然迁移到一个全新的构建架构模式上会给业务带来不确定性和新的问题，现在 Web 应用的工程复杂度已经超过了目前社区在工程能力上的建设。

所以 Rspack 有足够出现的动力，当然关于 Rspack 这里顺便聊一些八卦， Rspack 在正式开源前一周在公司内有一个技术分享，无论是参与的人数还是大家填写问题、回复的评率速度都远超我的想象，我忍不住跟对面同事说了一句“天下苦 Webpack 久已”，大家对于 Rspack 的进展和整体架构都非常关心，甚至有多个业务方在分享内问后续怎么合作，能帮忙迁移吗？

在本周五还有幸参加了@杨健 带来的 Rspack 创业史分享，在 Rspack 项目组成立前，其实 Web infra 团队已经在构建上做过了非常多的尝试和探索，在字节内不仅有庞大的 PC 端外场景也有很大庞大的 C 端端内场景，跨端场景必然需要提供对应的构建方案，他们针对业界内 Webpack、Esbuild、Parcel、Vite 等构建工具进行了详细的分析和调研最终基于 Esbuild 做了公司内的构建器 Speedy，一开始业务的反馈还是比较正向，但是随着时间的推移逐渐发现基于 Esbuild 来做应用构建器存在非常多的问题包括：HMR 热更新速度、tree shaking、拆包等等，业务的反馈也变成：speedy 不再 speedy。

随后 Rspack 专项成立，经过 11 个月的迭代终于在今天完成了项目的开源，说到这里我想说一下在一个商业化公司能投入这么大的人力去做一件投入周期长并且一开始就是奔着开源目标去做的项目、还可能受到社区的冲击和影响导致失败的项目，无论对于 Rspack 团队的个人还是对于更上一层的 Leader 而言都是不小的挑战，在团队内我也多次对于 Rspack 未走 Turbopack 更激进的路线而是走 Webpack 生态兼容的路线时在思考这是否是一个正确的决定，在第一次听到他们会兼容 Webpack 整套 hook 体系的时候我还是非常惊讶的，过程中也有很多质疑，他们能够坚持自己的路线并成功的在公司内一些比较大的业务上落地并且取得非常好的收益，那一刻我想他们应该受到了非常大的鼓舞，再到后面积极的拥抱社区和兼容社区生态，那一刻我真正的感受到了他们想改善整个前端工程生态，并且要把开源做好的决心。引用一下张磊在分享最后说的话，开源不是结束而是开始，”流水不争先，争的是滔滔不绝“！

写在最后，本文有感而发，Rspack 距离真正生态成熟达到 Webpack 的状态还有很长一段路要走，如何在能持续在保持现有性能的基础上，并让社区上更多的人参与进来，在性能和生态上找到平衡点让其真正的成为一个社区运营的项目，对 Rspack 团队而言是非常大的挑战。